A Chatbot Conversational System (CCS) is typically used to interact with a user via text or voice conversations that imitate natural human conversations, behavior, and interactions. Some CCSs provide a Conversational User Interface (CUI) and act as a translator between a user and an application with which a user desires to interact, thereby allowing a user to use voice or text to interact with the application through the CCS. For a CCS processing voice data, Automatic Speech Recognition (ASR) can be utilized to convert user speech or voice data to text. For processing text data, a CCS can use Natural Language Understanding (NLU) to recognize the meaning of the text data. In this way, the CCS can provide an engaging user experience and a lifelike, or human-like, conversational interaction between the user and the application.
Within the framework of some CCSs, the term “intent” is used to include one or more actions desired by a user. An intent is typically determined based on an analysis of a user's input voice or text data, i.e., conversational input data, provided to the CCS through the CUI. An intent typically has a corresponding action to be performed in response to the user's conversational input data.
For example, a user's intent may be to order a large pepperoni and sausage pizza from Acme Pizza House, a local pizza provider. The user's initial conversational input to the CUI of the CCS could be a spoken utterance, or perhaps text input, representing a phrase that invokes the intent. For example, the user's initial conversational input data may be an utterance, or text, of “I'd like to order a pizza.” After receiving this initial conversational data, the CCS analyzes the initial conversational data and identifies the term “order pizza” to determine that the intent is to “order pizza.”
However, the intent “order pizza” must be refined in order to fulfill the user's actual desire. Consequently, the CCS would then typically solicit and collect additional conversational data from the user to determine specifics about the “order pizza” intent, such as provider, size, toppings, etc. Operating within the traditional framework of some CCSs, this additional user conversational input data is typically termed a “slot,” which is additional conversational input data that is required to fulfill the entire user intent. For example, in our specific example, the CCS may respond to an utterance of “I'd like to order a pizza” with response conversational data, e.g., a request for slot data, of “Sure, from which pizza place would you like to order the pizza?” The user may then respond with additional conversational input data of “Acme Pizza House.”
Once this first slot conversational data is obtained, the CCS may then respond with conversational data of “Sure, what size?” The user may then respond with additional conversational data of “large.” Once this second slot data is obtained, the CCS may then respond with conversational data of “Sure, what do you want on it?” The user may then respond with additional conversational data of “pepperoni.”
Once this third slot data is obtained, the CCS may then respond with conversational data of “Is there another topping you want on it?” The user may then respond with additional conversational data of “yes, sausage.” Once this fourth slot data is obtained the CCS may respond with conversational data of “Is there another topping you want on it?” The user may then respond with additional conversational data of “No, that is it.”
Once this fifth slot data is obtained the CCS may respond with conversational data of “Where do you want the pizza delivered?” The user may then respond with additional conversational data of “Home.” The CCS may then determine it has enough slot data to fulfill the user's entire and correct “order pizza” intent.
Importantly, using a traditional CCS, slots, or slot data, are typically requested and obtained in a specific linear order with additional and sequential conversational data as shown in the example above. In addition, using a traditional CCS, the user's intent is only fulfilled once all the slot data associated with the determined intent is collected.
It is to be understood that, in various situations, it may be predetermined that the fulfillment of an intent may not require a slot, may require one slot, or may require any number of slots. However, importantly, using a traditional CCS, the slot data for each of the slots predetermined as required for a given intent must be collected before an attempt is made to actually fulfill the determined intent. This is true even if a given user does not actually require one or more of the slots to be addressed in order to satisfy that user's particular desire.
After a traditional CCS determines the intent from conversational input data and sequentially collects all necessary slot data to fulfill the intent correctly, the CCS typically invokes a fulfillment mechanism or application, such as an application used to actually order the pizza, to fulfill the intent. Then, once the pizza is ordered, the CCS may indicate fulfillment of the intent by the related fulfillment application by providing a user with additional conversational data of, “Got it, your pizza has been ordered.”
As noted above, with a traditional CCS, a conversation with the CCS is a linear process, i.e., the intent and each of the slots is processed in a sequential manner, and all slot data must be collected before action is taken to actually fulfill the intent. For example, the linear process may begin with the CCS determining an intent of a user from a specific conversational input data utterance. After determining the intent, the intent may require a first step of determining a first slot. After a first slot is determined, the intent may require a second step of determining a second slot, and so on. Under this example, each required slot may be based on the determination of a prior slot, such that an intent triggers a chain of sequential slot determinations, but each slot must be determined before the intent is fulfilled.
Traditional linear approaches to a CCS have proven effective for some applications, such as customer care solutions including on-demand troubleshooting of a device error in which a customer is instructed to follow a series of diagnostic steps to resolve the problem with the device. Such diagnostic steps traditionally lead to resolution of device problems because such steps model the way human technicians behave when problem-solving device errors. Consequently, the linear and sequential steps of collecting slot data seems like a natural type of interaction to the user.
However, a series of required sequential steps is often cumbersome and contrary to how human users approach other tasks, for instance, a desire to extract information from data management systems in the form of reports customized to the user's current needs. Typically, users desire to extract such information through reports that they historically, and naturally, customize in a non-liner, buffet-like, manner. In addition, users often desire intermediate reports that do not necessarily include all customization options that are eventually desired. Users then often want the option to create new reports with additional, or different, report customizations.
For example, when using traditional, i.e., non-CCS, methods of requesting a report, a Graphical User Interface (GUI) is provided through the data management system and the user is presented with a display of many, or even all, customization options for the creation of reports. These customizations options are typically presented to the user visually, and often simultaneously. In this traditional non-CCS approach, the user is then free to select, and thereby interact with, only those customization options of interest to the user. Using this traditional approach, the user is also free to ignore, i.e., not interact with, all the undesired customization options. In addition, using this traditional approach, the user is also free to add customizations once a given report is generated. Consequently, traditionally, a user interacts with customization options visually and on a highly selective, ad hoc, non-linear, and cumulative basis. However, currently, when conversational data, such as voice data or text data is provided, this intuitive and highly flexible traditional approach to report customization is not available due to the need of current CCS based systems to interact with the user via a linear series of required sequential steps.
For example, a traditional dialog box GUI for report customization may include several customization options in a single display, including the options to present the orientation of the report in either landscape mode or portrait mode, consider only specified date ranges, employ any one or more potential data filters, etc. Traditionally, a user expects to be able to select, ignore, or add-on these report customization options through the GUI without having to walk through all the possible options, and with the capability to see intermediate reports based on a sub-set of customization options. Again, this is possible because the user interacts with a visual user interface display to make selections.
In contrast, if an attempt were made to use a currently available CCS and conversational data to generate a customized report from a data management system, the CCS would require the user to walk through a complete set of sequential steps/questions to accept, reject, or otherwise provide a response for each potential customization option, including undesired and even irrelevant customization options, all in a linear fashion. This would be done using conversational data in the form of a series of questions and answers provided, and responded to, in a pre-defined, and static, sequence, to collect the necessary slot data for each slot/potential option. Only after entire series of questions and answers was walked through, i.e., the slot data for each slot/potential option was collected, would the desired report be generated.
Consequently, the traditional linear approach of a CCS to sequentially collect slots of input data for a customized report is an inefficient and non-intuitive approach for users that is unable to mimic the way a user traditionally, and intuitively, expects to create and customize a report from a data management system. Therefore, traditional CCS approaches to report customization are not considered an effective, flexible, or efficient option.
As discussed above, there is currently a significant need in the data management arts to provide a CCS based report customization method and system capable of interacting with users and data management systems through the CCS in an efficient and non-linear manner to create, customize, and save, user reports; thereby providing a more effective CCS-based customized report generation system.